TL;DR

Publish Smoke was not broken — it was right. It has been red on main since #3100 introduced it because it caught a real, currently-shipping bug on its very first run: npx create-objectstack && pnpm install exits 1 for any user on pnpm 11.

This fixes the product bug, not the gate.

The bug (reproduced against published 15.1.1)

$ npx create-objectstack@latest myapp --skip-install && cd myapp
$ pnpm install          # pnpm 11.13.1, what corepack gives a fresh machine
[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: better-sqlite3@12.11.1, esbuild@0.28.1
$ echo $?
1

pnpm 11 turned an unapproved dependency build script from a warning into a hard error. The blank template declares no approvals — no packageManager, no pnpm-workspace.yaml, no .npmrc — so the first command a new user runs fails.

Why both approval keys

Neither key alone covers the supported range — measured, not assumed:

The decision this PR makes: the gate stays unpinned

The suggested quick fix was to stamp packageManager into the generated app so it installs with the repo's pinned pnpm 10. That turns the gate green by silencing a true positive — it would test a pnpm no downstream user runs, which is the same "in-repo settings hide the user's real resolution" mistake as #3091, i.e. precisely the failure class this gate exists to catch.

So the smoke's pnpm stays unpinned and keeps testing what a fresh machine gets. The tradeoff is real and recorded in the script header: a new pnpm major can turn this red with no code change here. That is signal, not noise — it means a fresh install is broken for new users and the template needs updating. Exactly what happened here.

Why the gate couldn't see its own blind spot

publish-smoke.sh hand-wrote the app's entire pnpm-workspace.yaml, declaring onlyBuiltDependencies itself. A locally-authored declaration proves nothing about what the template ships — that is how this bug stayed invisible to a gate designed to find it. The script now appends its tarball overrides to the file the template ships, and fails loudly if the scaffold declares no approvals.

Changes

• templates/blank/pnpm-workspace.yaml (new) — the actual product fix.
• scripts/publish-smoke.sh — append overrides to the template's file; assert approvals exist; record the no-pin rationale.
• template-consistency.test.ts — drift ratchet, matching the file's existing purpose.
• changeset — patch to create-objectstack.

Verification

Ran the real gate locally under CI-identical pnpm resolution (corepack shim: 10.31.0 in-repo, 11.13.1 in the app dir — confirmed, since a plain local run uses global pnpm 10.33 and would not reproduce the failure at all):

== Auth probes (the #3091 failure surface)
  ok — GET /auth/get-session (anonymous) → 200
  ok — POST /auth/sign-up/email → 200
  ok — POST /auth/sign-in/email → 200
== REST CRUD probes (seeded dev admin)
  ok — POST/GET/PATCH/DELETE /data/smoke_app_note → 201/200/200/200
== Scanning server log for error-level output
  ok — no error/fatal log lines
== Publish smoke passed (pack mode)

Controls, so none of this is a tautology:

• Strip allowBuilds → reproduces the exact CI error (exit 1); restore → clean. The fix is load-bearing.
• Ratchet controls → template deleted fails 3 tests; allowBuilds removed while onlyBuiltDependencies kept (the exact ObjectLogger file destination silently no-ops in ESM builds #3110 shape) fails exactly 1, with an actionable message.
• Confirmed pnpm-workspace.yaml survives pnpm pack, so the fix actually ships.
• eslint clean, 8/8 tests, bash -n clean, pnpm build green.

Found in passing (not fixed here)

pack strips .gitignore from nested template dirs, so scaffolded projects ship no .gitignore — node_modules/ and .env are un-ignored for every new user. Real, pre-existing, out of scope; filed separately.

🤖 Generated with Claude Code